Alde ADA 5 #1

home *** CD-ROM | disk | FTP | other *** search

/ Alde ADA 5 #1 / ADA CD-ROM - Alde Publishing.iso / news / asr009.doc < prev next >

Wrap

Text File | 1988-05-03 | 51.7 KB | 1,161 lines

ASR Newsletter, Issue 9, Dec 86 - Jan 87 Ada (tm) Software Repository (ASR) Newsletter Issue 9, Dec 86 - Jan 87 Richard Conn, Newsletter Editor Published by Echelon, Inc. THIS ISSUE Page I. THIS NEWSLETTER 1 II. ASR-RELATED INFORMATION 2 1. ASR and DDN Resource Handbook 2 2. ASR Books 3 3. GKS Transportability 3 4. Lost Mail from the Archive Server 3 5. Automatic Archiving of ADA-SW Messages 4 6. User Feedback/Bug Reports 5 7. Future ASR Submission 5 8. ASR Survey and Activity 6 III. ITEMS OF INTEREST 9 1. Ada Texts and Object-Oriented Programming 9 2. Success of Software Reusability 10 3. More on Software Reuse 11 4. OOP 11 5. Request for Papers for Ada Letters 12 6. COMPOOLS - Ada and Software Engineering 12 7. Portability Failure 14 IV. NEW SUBMISSIONS TO THE ASR 16 1. AJPO Validation Procedures and Guidelines 16 2. Validated Ada Compilers List 16 3. Compools in Ada 16 4. Date 16 5. Math Functions 17 6. FORTRAN Namelist Capability 17 7. Sort Array Update 17 8. Ada, Software Engineering, and Common Blocks 18 9. Planned Ada Implementations 18 10. Documentation Update from ADA20 18 ---------------------------------------------------------------------------- I. THIS NEWSLETTER This issue covers two months, December 1986 and January 1987, unlike a regular monthly issue of the Ada Software Repository Newsletter. The level of activity has been quite high, and, supplemented with the information flow from Ada Expo '86, there is a lot to talk about. Various articles are appearing in several publications as a result of topics discussed at Ada Expo '86. The AdaJUG (Ada/JOVIAL Users Group) has recently released its minutes from Ada Expo '86, and these minutes include copies of the transparencies shown during various presentations. This document is a "must have." COMPCON '87, the 32nd International Conference of the IEEE Computer Society, will be held at the Cathedral Hill Hotel in San Francisco from 23 to 27 February. It should prove to be a very useful conference, covering a wide range of topics (including Ada and Software Reusability). Page 1 ASR Newsletter, Issue 9, Dec 86 - Jan 87 ---------------------------------------------------------------------------- II. ASR-RELATED INFORMATION 1. ASR and DDN Resource Handbook ___ ___ ___ ________ ________ Date: Fri 19 Dec 86 07:11:00-MST From: Rick Conn <RCONN@SIMTEL20.ARPA> Subject: ASR and DDN Resource Handbook My new book, "The Ada Software Repository and the Defense Data Network - A Resource Handbook," is out now. I received my copies yesterday, so all of you who placed orders already should be getting yours soon. The book is in direct support of the ASR, designed to answer many (hopefully all) of the commonly-asked questions about the ASR and DDN. The book is a resource handbook. Its objective is two-fold: (1) to answer many of the basic questions about the ASR and the DDN, including details on the available resources, and (2) to provide many pointers for more information and more extensive questions on/about the ASR and the DDN. The stack of notes from which I created the book was two feet high, covering 10 years of ARPANET and DDN use. Topics covered include: 1) A history and tour of the Ada Software Repository, Defense Data Network, and several major software repositories and information resources on the DDN, 2) How to find out what is in the Ada Software Repository, how to use the Ada Software Repository, and how to keep in touch with the Ada effort through the DDN, 3) How to use the DDN and its facilities -- Electronic mail, File Transfer Protocol (FTP), Remote Terminal (TELNET), and the Terminal Access Controller (TAC) -- and what the DDN can do for you (with lots of examples), 4) How to access the Defense Data Network (and SIMTEL20 in particular) from BITNET, CSNET, USENET, and other computer networks, 5) How to use SIMTEL20 and its repositories of software: the Ada Software Repository, the three CP/M repositories, the two IBM PC repositories, the UNIX/C repository, the ZCPR3/Z-System repository, and the miscellaneous repository (which includes software for VAX/VMS, TOPS-20, and other operating systems), 6) How to use electronic mailing lists on the DDN and what they have to offer, and 7) How to communicate and transfer files between network-based mainframe computers and personal computers. If you are interested in ordering the book, contact: New York Zoetrope, Inc. 838 Broadway New York, NY 10003 800/242-7546 This 200+ page paperback costs $16.95. Again, this book is intended as an introduction ONLY to the ASR and the DDN. I hope you find it to be of value. ========== Page 2 ASR Newsletter, Issue 9, Dec 86 - Jan 87 2. ASR Books ___ _____ Date: Fri 19 Dec 86 07:24:15-MST From: Rick Conn <RCONN@SIMTEL20.ARPA> Subject: 2 books on the ASR This new book is the second book published on the ASR. I wrote both of them, and they serve two different purposes. The first book is the "Master Index to the Ada Software Repository." It is 500+ pages long, loose-leaf in format, and a living document that will be updated as the ASR grows. The Master Index itemizes the contents of the ASR, detailing each item of software and information. The information in this book is also contained in the online documentation system, which is updated each time the ASR changes. The Master Index provides a more convenient form for this information. The Master Index is available from Echelon (see the newsletters). The second book is "The Ada Software Repository and the Defense Data Network - A Resource Handbook," and, while it contains a little information on the contents of the ASR, it is mainly tutorial and reference in nature. ========== 3. GKS Transportability ___ ________________ Date: 19 Dec 86 06:07:00 PST From: "CONTR47" <contr47@nosc-tecr> Subject: A transportability data point The GKS/Ada device independent code is about 130,000 lines of code. It was developed on a Data General Ada system and ported to Dec VAX Ada system. About 100 lines of code had to be modified, maily for 2 reasons; 1. Bad code accepted by DG and 2. Good code rejected by DEC. The code was designed for portability so it is no surprise that porting problems were compiler problems. I believe that within 5 years we will see this sort of problems go to near zero and then portability will be mostly a design problem. Regards, Sam Harbaugh ========== 4. Lost Mail from the Archive Server ____ ____ ____ ___ _______ ______ Date: Wed, 19 Nov 1986 21:34 MST From: WANCHO@SIMTEL20.ARPA Subject: Lost Mail from the Archive Server First of all, please address your requests to ARCHIVE- REQUEST@SIMTEL20.ARPA, *NOT* ARCHIVE-SERVER. That latter address is what appears as the Sender in the replies you receive. If you reply to that reply in the hopes of getting more files *and* your mail program is misimplemented in that it forms the header using the Sender: field, rather than the From:, your message will be bit-bucketted when it gets here. In fact, ALL mail addressed to ARCHIVE-SERVER, including mailer reject notices, is being discarded unseen by any human. Secondly, as of this past Saturday, we were forced to reduce the size of our host tables to improve Internet performance - the host tables share the same section of memory with the Internet free buffers. This rather drastic reduction was accomplished by removing all host aliases from the distributed table, along with all host entries which do not advertize at Page 3 ASR Newsletter, Issue 9, Dec 86 - Jan 87 least one TCP service: FTP, TELNET, or SMTP. What this means is that if you are sending a message through an Internet host which is not using its Official Host Name, or does not advertize one of the TCP services listed above, do not expect to see a reply from us. Finally, I have noticed several messages coming to us from hosts which are not even listed in the original host tables we receive from NIC. These hosts are probably registered under a Domain. However, we do not have access to a domain lookup service at this time, and we don't have the resources to implement our own. If your requests come to us from such a host, do not expect a reply either. One more thing: several weeks ago I patched our mailer to keep trying to send mail hourly for five days instead of three. This has helped somewhat in getting mail through to hosts which are taken down for a weekend or the long three-day weekends. It has even helped in getting replies back to the BITNET requestors via WISCVM, but not completely. I understand that work is in progress to try to reduce the volume of mailing list mail through that host in the hopes of increasing the chance for other mail to get through. What I have seen is that only parts of multi-part replies from the server getting through, requiring the requestor to re-request *all* parts of the file. There *may* be an extension made to the server, after the first of the year, to allow for selected parts to be sent. ========== 5. Automatic Archiving of ADA-SW Messages _________ _________ __ ______ ________ Date: Wed 26 Nov 86 06:42:03-MST From: Rick Conn <RCONN@SIMTEL20.ARPA> Subject: Mail archives There have been several requests recently for old messages which were posted to ADA-SW. All messages sent to ADA-SW are automatically archived in PS:<ARCHIVES.ADA-SW> on SIMTEL20. You may freely transfer these files and review them. Some details follow: @dir ps:<archives.ada-sw>, @@len @@ PS:<ARCHIVES.ADA-SW> Bytes(SZ) ADA-SW.ARCHIV.60325 510671(7) ADA-SW-ARCHIV.TXT.1 249064(7) Total of 298 pages in 2 files @filusx ps:<archives.ada-sw> name # refs, rate/month, size. ADA-SW-ARCHIV.TXT.1 77 3 98 pgs ADA-SW.ARCHIV.60325 8 0 200 pgs ========== Page 4 ASR Newsletter, Issue 9, Dec 86 - Jan 87 6. User Feedback/Bug Reports ____ ____________ _______ Date: Mon 15 Dec 86 05:27:15-MST From: Rick Conn <RCONN@SIMTEL20.ARPA> Subject: Re: SIMTEL-20 SURVEY 1. There is a "Consumer Reports" function in two basic forms. The first is the ADA-SW email list (which is echoed in the ASR Newsletter) and the second is the CMM files (user comments files). Of course, if people have problems and don't bother to report them, then the "Consumer Reports" are lacking. 2. There is an extensive database function. The Online Documentation System, which is updated every time a change is made to the ASR, and the "Master Index" book both provide details on the contents of the ASR by subject area. The book includes an extensive table of contents and index. ========== 7. Future ASR Submission ______ ___ __________ Date: Mon, 5 Jan 87 08:06:39 est From: choinier@mitre.ARPA (Captain Jacques Choiniere USA) Full-Name: Captain Jacques Choiniere USA Subject: reply to Jan Skarvall I am a monitor of a tranlator project. The versions translated are HONEYWELL COBOL 68 and FORTRAN 66 to Ada on the DEC Ada VAX Compiler. A DG was used at first, but was not really up to the task. Our final technical report has been turned in, and the Institute for Defense Analysis is doing the testing for us. Upon test completion and the normal red tape, the software will be released to the Simtel20. Expect it there in 3 to 4 months. Jacques C. Choinere CPT, USA WIS JPMO/Advanced Technology Division Address: WIS JPMO/ADT ATTN: CPT Choiniere Washington, DC 20330-6600 or jcc@mitre phone (703) 285-5066 ========== Page 5 ASR Newsletter, Issue 9, Dec 86 - Jan 87 8. ASR Survey and Activity ___ ______ ___ ________ Date: 6 Jan 87 15:46:02 GMT From: decvax!wanginst!pollice@ucbvax.Berkeley.EDU (Gary Pollice) Organization: Wang Institute of Graduate Studies, Tyngsboro, Mass. Subject: SIMTEL-20 survey results A while back I asked for comments on the usefulness of the SIMTEL-20 public domain repository. Thanks to all of you who responded. I received 16 responses. They are briefly summarized below. - 2 people did not know about the repository. - 2 people thought the repository was not only useful, but really great. - 10 people thought that there were some useful pieces of software in the repository, but that the quality was not good enough to be used without some changes. - 2 people thought the software was not useful at all. Of those who used the repository, the biggest complaints were: - poor documentation of the software, - inability to find the right piece of code quickly and - inconsistent quality. Sorry it took so long to get this posted, but I was hoping for more responses. -- Gary Pollice pollice@wanginst (CSNET) Wang Institute of Graduate Studies decvax!wanginst!pollice (UUCP) Tyng Road, Tyngsboro, MA 01879 (617) 649-9731 ------------ Date: Wed 7 Jan 87 06:18:10-MST Subject: TOP 30 - ASR Activity Report The following list shows the 30 most popular files in the Ada Software Repository. Popularity is judged by the number of times they have been referenced. Note that the rate/month column provides a further indication of ASR activity, showing the number of times these files have been referenced per month since the files were placed in the ASR. A few items about these 30 files: 1) the majority are reusable software components (17 files from PD:<ADA.COMPONENTS> are in the list) and PROlogue files for reusable software components (7 of the 17 files from PD:<ADA.COMPONENTS> are PRO files) 2) one "major" tool is in this list: a Pretty Printer (PD:<ADA.PRETTY-PRINTERS>PRET.SRC) 3) there is interest in AI; the three files associated with the simple Expert System are in the list (PD:<ADA.AI>EXPERT.*) 4) people have learned to use the PROlogue files to "look before they leap"; 9 of the files are PRO files; PRO files provide abstracts, author affiliations, host and target environments, and disclaimers Page 6 ASR Newsletter, Issue 9, Dec 86 - Jan 87 5) micro-based communications is of interest; two of the files provide information on Kermit 6) "lessons learned" and, as I interpret, dealing with the "old guarde" is of interest; the tech report from TI (which provides metrics such as lines of code and manhours) and the Ada-to-FORTRAN interfacing document (ADA1FOR.DOC) are on the list 7) graphics is of interest; two of the files document GKS 8) benchmarks are of interest (actually, results of benchmarks - see BENCH.DOC) There are 779 files in the ASR at this time, so these 30 files represent less than 4% (in terms of number of files) of the ASR. If you are interested in the full report, which lists all files in the ASR, see the file FILEUSE.DOC in PD:<ADA>. FILEUSE.DOC is updated frequently (everytime the online documentation system is updated). Rick Conn -------- 30 Most Popular Files in the Ada Software Repository as of Tuesday, 30 Dec 1986 name # refs, rate/month, size. <ADA.COMPONENTS>LIST.ADA.2 352 13 7 pgs <ADA.GENERAL>KERMIT.DOC.1 297 11 7 pgs <ADA.EDUCATION>TITR.DOC.1 290 14 28 pgs <ADA.COMPONENTS>SAFEIO.ADA.2 288 11 4 pgs <ADA.COMPONENTS>LIMPRIOR.ADA.2 285 11 3 pgs <ADA.COMPONENTS>VDT100.SRC.1 284 11 6 pgs <ADA.COMPONENTS>LIST.PRO.2 283 11 2 pgs <ADA.BENCHMARKS>BENCH.DOC.1 280 17 3 pgs <ADA.AI>EXPERT.ADA.1 277 21 15 pgs <ADA.COMPONENTS>SAFEIO.PRO.2 275 10 2 pgs <ADA.COMPONENTS>ABSTRACT.SRC.1 273 15 224 pgs <ADA.COMPONENTS>PRIOR.ADA.2 272 10 3 pgs <ADA.COMPONENTS>QSORT.SRC.1 271 11 3 pgs <ADA.COMPONENTS>DSTR1.ADA.1 271 13 4 pgs <ADA.AI>EXPERT.PRO.1 269 20 2 pgs <ADA.COMPONENTS>VDT100.PRO.1 267 11 2 pgs <ADA.COMPONENTS>LIMPRIOR.PRO.2 266 10 2 pgs <ADA.GKS>GKSUSER.DOC.1 262 15 99 pgs <ADA.GENERAL>KERMICRO.DOC.1 262 9 12 pgs <ADA.EDUCATION>ADA1FOR.DOC.1 262 12 3 pgs <ADA.PRETTY-PRINTERS>PRET.SRC.1 259 14 131 pgs <ADA.COMPONENTS>CAS2.ADA.2 258 11 3 pgs <ADA.EDUCATION>OBJECT.DOC.2 257 11 4 pgs <ADA.COMPONENTS>PRIOR.PRO.2 256 10 2 pgs <ADA.GKS>GKS.PRO.1 255 15 2 pgs <ADA.COMPONENTS>PARSER.PRO.1 255 14 2 pgs <ADA.COMPONENTS>CAS2.PRO.1 255 11 1 pgs <ADA.GENERAL>COPYRITE.DOC.1 254 10 9 pgs <ADA.COMPONENTS>DSTR1.PRO.1 254 12 2 pgs <ADA.AI>EXPERT.DAT.1 254 19 1 pgs Page 7 ASR Newsletter, Issue 9, Dec 86 - Jan 87 ------- Date: Wed 7 Jan 87 06:26:57-MST From: Rick Conn <RCONN@SIMTEL20.ARPA> Subject: About the activity report The activity report I just sent out draws some conclusions from the data provided by FILEUSE.DOC. I believe these conclusions to be reasonable, but not necessarily correct, particularly since I receive very little feedback from the users (note that only 16 people responded to the recent ASR user survey). I got a lot of feedback as a result of my attending Ada Expo and giving a talk, and most of it was positive and constructive. I'll be giving several more talks over the next few months (see the next newsletter, which will be out within a week), and I invite your feedback during these talks and conferences. Rick Page 8 ASR Newsletter, Issue 9, Dec 86 - Jan 87 ---------------------------------------------------------------------------- III. ITEMS OF INTEREST 1. Ada Texts and Object-Oriented Programming ___ _____ ___ _______________ ___________ Date: Wed, 17 Dec 86 01:52:04 PST From: larry@Jpl-VLSI.ARPA Subject: Ada texts + Object-Oriented Programming I at least read the first chapter of most Ada books that come out and I still recommend Grady Booch's Software Engineering with Ada for most beginners. Note that Booch just came out with a third edition. I'm also impressed with Putnam Texel's book. For Pascal experts Habermann & Perry's Ada for Experienced Programmers is good, with many examples all worked out both in Pascal and then in Ada. Narain Gehani and Norm Cohen each have a book that is a bit more advanced than Booch or Texel. J.G.P.Barnes text jumps right into nitty-gritty, which some people like who disdain "all that software engineering propaganda." But don't take anyone else's word for the one (or more) book(s) you need. Skim the first chapter, look at the table of contents, and read the introduction, then pick the clearest one. ************************ One element of Booch's book may not be clear: object-oriented programming. I assume this because at conferences and in various Ada articles at least half of the people who sling the term around don't seem to know what it is, and most of the others are too close to details of how OOP is done to see the overall picture, the commonalities shared by Ada, SmallTalk, LisP Flavors, and so on. I hope the following clears this up (and maybe stimulates some discussion on this list). An object in a programming language is an analog of some external object. The most important characteristic of both is a boundary of some kind. The important dimensions of the boundary depends on what problem you want the computer to solve. An engineer designing computer circuitry might be interested in digital pulses, with two crucial dimensions, time and voltage, which form the beginning, end, "top," and "bottom" of each pulse. Many objects have not only boundaries but a skin at the boundary. This protects the interior from the exterior, and vice versa. The more advanced programming languages also have these skins: in Ada each compilation unit has a specification which serves this purpose. (The unit with the "strongest" skin is the package.) There is also typically some control over the "permeability" and "transparency" of the skins: in Ada private types, the Shared Pragma, and a few other features perform these functions. Another aspect of objects is that they fall into classes which have the same attributes and capabilities. This is useful if you can create subclasses of objects that inherit attributes/capabilities from the superclass; this saves the programmer from duplicating the effort of specifying what is inherited. In Ada derived types, generics, and (in one sense) overloading are inheritance mechanisms. Other languages provide additional or alternate mechanisms to support object-oriented programming. Whatever the language, each mechanism always has advantages and costs. The software engineer makes trade-offs to produce an optimum system. For instance, SmallTalk is more useful than Ada for producing and modifying prototypes; Ada produces much more efficient code. Object-oriented programming is really an attitude rather than a Page 9 ASR Newsletter, Issue 9, Dec 86 - Jan 87 collection of mechanisms; it can be used in relatively primitive languages such as ForTran or Assembler. OOP focuses the programmer's mind on the enduring components of the desired system, which tends to produce programs that need little change or can be easily changed. It also promotes designs that use elements from the problem area; that is, the programmer tends to think in terms of spaceships and thrusters rather than data structures and subprograms, or invoices and sales, etc. This takes advantage of the knowledge and intuitions the programmer has from (or so we hope!) knowing the problem area. It also tends to reduce the sort of "painted into a corner" errors that come about when programmers jump into coding without thinking through all the requirements of the system they're developing. OOP is sometimes thought of as antagonistic to older ways of designing systems. My feeling is that it is more of a superset of previous approaches. Functional decomposition focuses on the activities of a desired system, data-structure approaches focus on static data relations, data-flow combines the two with an emphasis on activities and with a more implementation-oriented mindset. As with any tool, there are limits and problems with OOP--something which no-one I know in the Ada community has addressed. I have to admit I haven't done much along those lines myself. It does seem to me that there are probably problem domains in which OOP would have problems, say areas where objects with boundaries don't exist. And there may be problems that could better be solved by a more mathematical or symbolic-logic approach. ========== 2. Success of Software Reusability _______ __ ________ ___________ Date: Wed, 17 Dec 86 07:53:37 est From: falgiano@mitre.ARPA (Frank Falgiano) Full-Name: Lt Col Frank Falgiano Subject: Tools use off the repository The success or failure of any reuse effort in software is directly proportional to the quality of specific feedback. Saying that there are problems in the repository don't give the implementers or users a chance to fix the problems. In terms of feedback here is what is needed: - identification of problem areas, - type of problem, ie run-time performance, core hog, task wild, lack of software engineering, no internal documentation, poor exception handling, difficult to follow execution path during maintenance analysis - fixes or work arounds that have been implemented to include why there are advantages The point is there is no such thing as a free lunch. Reusable software requires work to keep it current and flexible. ========== Page 10 ASR Newsletter, Issue 9, Dec 86 - Jan 87 3. More on Software Reuse ____ __ ________ _____ Date: Wed, 17 Dec 86 10:49:27 est From: karl@grebyn.com (Karl A. Nyberg) Subject: Re: Tools use off the repository One interesting comment made by Lt. Col. Courtwright (Terry - correct me if I'm wrong here) at the Washington, DC SigAda Chapter meeting last Wednesday (10 December 1986) was made with regard to use and commercialization of the WIS software placed in the repository. He stated that he (whether speaking for himself, the WIS project, the DoD, etc. - I don't know) would have no problem with contractors / vendors picking up the software that WIS had developed and put into the public domain, investing additional work into cleaning up the software, adding functionality, documentation, etc., and then turning around and selling it back as a product. I believe that he mentioned in particular this route was being taken by several contractors / vendors with regards to some of the GKS tools in the repository. Thus, if you invest the effort to make the "free" software usable to you, and perhaps to others, you might be able to recoup some of your investment in this manner. In cases where these tools were developed as a one-shot program (i.e., where nobody's getting paid to support or maintain them now), it might indeed be useful (and perhaps profitable) for somebody to pick up the code and provide such enhancements and ongoing support. There may not be any free lunches, but that doesn't mean they have to be expensive. A significant amount of investment has already been placed in the initial development of this software, and can perhaps be leveraged profitably. ========== 4. OOP ___ Date: Wed, 17 Dec 86 10:40:13 PST From: "LT Scott A. Norton, USN" <4526P%NAVPGS.BITNET@WISCVM.WISC.EDU> Subject: Re: Object oriented programming (OOP) Thank you, Larry, for the clear explaination of OOP. I would like to add a few comments to address the design phase that preceeds OOP. These comments are based on the work I've read of Dr. David Parnas. To enable OOP to "tend to produce programs that need little change or can be easily changed," the objects that are defined should encapsulate those aspects of the project likely to change. Parnas calls these details the secrets of the module that defines the objects. Then, when a requirement changes, the program change is isolated to that module. For object-oriented programming to be totally effective, the design of the system must explicitly consider what design decisions are likely to change, and use that as the criterion to define objects. As Parnas found in his study of the A-7 aircraft's tactical program, this design requires significant amounts of research, and should not be a decision that the programmer makes sitting at a terminal. The designers must invest extra time before coding starts. ========== Page 11 ASR Newsletter, Issue 9, Dec 86 - Jan 87 5. Request for Papers for Ada Letters _______ ___ ______ ___ ___ _______ Date: 28 May 1986 13:41-PDT Subject: REQUEST FOR PAPERS FOR ADA LETTERS From: ECOMER@USC-ISIF.ARPA REQUEST FOR PAPERS If you or anyone you know is thinking about writing a paper about Ada for submission to Ada LETTERS, now is a good time to do so. Potential topics include: o Ada language features/peculiarities o Ada applications o Ada methodologies o Ada environments/tools o Ada training o Ada-based languages Ada LETTERS' queue of papers is at a low point so time from submission to publication is at a minimum. Send your paper to: Dr. Ron Brender Associate Editor of ADA LETTERS Digital Equipment Corporation 110 Spit Brook Road ZK02-3/N30 Nashua, New Hampshire 03062 Any comments about this request for papers can be addressed to Kaye Grau, editor of Ada LETTERS, via ecomer at ada20. ========== 6. COMPOOLS - Ada and Software Engineering ________ _ ___ ___ ________ ___________ Date: 26 Dec 1986 03:14:33 PST Subject: We're getting there - slowly From: Edward V. Berard <EBERARD@ADA20.ISI.EDU> Until November of 1982, I was violently anti-Ada. I had heard the arguments of C.A.R. Hoare, and had agreed with them somewhat, but that was not the main reason for my objections to the introduction of the language. Since 1978, I have provided training and consulting to clients in the U.S., Canada, Europe, and Japan. These services were software engineering related, i.e., they covered topics from programming languages to structured methodologies to software engineering management to computer hardware. A great deal of my work required that I travel to the location of my clients. Since 1978, I have been to literally hundreds of different shops, and have talked to literally thousands of programmers and managers. What I saw had a profound impact on me. Before I began this work, I was under the false impression that there was little difference between the state-of-the-art and the state-of-the-practice in software engineering. I was very wrong. A majority of the people that I saw were very poorly trained -- managers *and* programmers. Those that had even a glimmer of an idea of what sound software engineering entailed were often (but not always) Page 12 ASR Newsletter, Issue 9, Dec 86 - Jan 87 restricted by poor management, buyer indifference, contracting office stupidity, and a very entrenched "old guard." "Most programmers and managers can't get out of the way of their own two feet with languages like COBOL and FORTRAN.", I argued, "... and you're going to give them Ada? ... a language that makes PL/I look like BASIC!" What changed my mind was a presentation I attended given by Larry Druffel, then director of the Ada Joint Program Office. He said something that shocked me. The Department of Defense was not merely introducing a new programming language, he said. The DoD realized that it would be sound software engineering practice, *not the simple introduction of yet another programming language*,that would help alleviate the proverbial software crisis. The DoD was talking about items like STARS, the Software Engineering Institute, Ada Programming Support Environments, Educationman (now ASEET), Methodman, and others. The message was software engineering, not the syntax and semantics of Ada. In the four years since I heard Larry Druffel give that presentation things have changed dramatically. Yet there has been relatively little movement on the most important issue. Many people seem to think that the most important issue regarding Ada technology is the syntax and semantics of the language itself. Programs like STARS seem to be in trouble. Far too many managers and programmers think that all that is required is "a week or two of hands-on training in the syntax of the language." Contracting offices still fill requests for proposal with meaningless "buzzwords." Yes, I know the message is getting through very slowly. Eventually both the government and software practitioners will stop "shooting themselves in the foot" with such predictability. I also know that the vast majority of these people are not stupid, just horribly misguided. We all want to do the best job possible. What set me off on this tirade? An electronic mail message informed me today that the Ada Software Repository had accepted a contribution which would allow Ada programmers to mimic FORTRAN's common blocks. Almost two decades ago, IBM researchers (e.g., Larry Constantine) showed the damage that "global data" could do to a system. Without sound software engineering behind it, and the presence of an "Ada mindset," Ada is an accident looking to happen. Please do not try to duplicate the software engineering mistakes of FORTRAN, COBOL, C, Pascal, and assembly language in the Ada language. But not to worry. Ada compilers are inanimate objects. When the project blows up, you can always blame Ada. Now what was that about a poor workman blaming his or her tools? -- Ed Berard -------- Date: Tue, 30 Dec 86 01:50:48 PST From: larry@Jpl-VLSI.ARPA Subject: Globals + Texts + Simplicity GLOBAL DATA AND SW ENG The only reason I can see for Ada versions of ForTran COMMON or HAL/S COMPOOLS is for quick one-for-one translations of code from ForTran or HAL/S to Ada. If one needs global data there are better ways to do it. Norm Cohen discusses this at length (with appropriate cautions) in his _Ada_as_a_Second_Language_. See especially pages 293-7 and 370-3. There are times, of course, when global data is an optimal solution to a problem. It's the nature of any kind of engineering that trade-offs Page 13 ASR Newsletter, Issue 9, Dec 86 - Jan 87 always have to be made. But the number of people with SW responsibilities who don't have any SW engineering knowledge is a national disgrace shared equally by education and industry. I find it sourly ironic that the military--supposedly the least foward-looking, "with-it" American institution--is the biggest supporter of SW engineering. BEGINNING TEXTS Cohen's book has two notably useful features. All chapters have a Summary section; some of the more difficult ones have a Details section which can be skipped by those who need a less complete discussion of the topic. Later one can make a second pass over the book, reading the details sections for a more complete understanding. Further, there's a lot of pragmatic advice about how to use language features. This makes for a book of 800+ pages, but the advice (and the examples and clear writing) actually makes it easier to read than shorter books, because it gives a context for the parts of Ada. ADA A SIMPLE LANGUAGE? Ed made a comment that reminded me of what I consider a myth: Ada's complexity. We always over-estimate the complexity of a familiar language and under-estimate the one(s) in which we're expert. (The fish-in-water syndrome.) And until the last year or two there weren't very many validated compilers around for people to use. So the viewpoint we got was that of the designers or implementors, which is very different from (what is becoming) the typical user. I suspect that in a few more years we'll be hearing a new cliche: that Ada is SIMPLER to use than previous languages. For, after internalizing the Ada mind-set and developing a reflexive mastery of its syntax, the user can forget about bits, bytes, subprograms, and data (at least until it becomes time to do trade-offs and optimizations). Instead, s/he'll write programs using elements in the problem domain. Larry @ jpl-vlsi.arpa ========== 7. Portability Failure ___________ _______ Date: Mon, 22 Dec 86 10:55:52 EST From: WMORTENS%ESTEC.BITNET@WISCVM.WISC.EDU Subject: Reply to: How Portable ? I have some sympathy for the 'resident skeptics' of E. Hauser, based on an experience we had in 1985: In 1985 ESA issued a research contract to evaluate the use of Ada for space applications. The work consisted of redesigning a 5000 lines FORTRAN77 program to Ada. The program simulated the dynamics and controls of the GIOTTO spacecraft. After design and testing of the Ada version, the last workpackage of the contract contained a study of the portability of the Ada code. Since the Ada version was developed by Ada 'wizards' and the LRM etc. gives high hopes for portability, we did not expect much trouble, and allocated one full working day per compiler for testing. The program was developed using the DG/Rolm Ada compiler, and was attempted ported to SIX other VALIDATED compilers and two pre-release Page 14 ASR Newsletter, Issue 9, Dec 86 - Jan 87 compilers. ******************************************** * NONE OF THE EIGHT ADA COMPILERS * * COULD COMPILE AND RUN THE PROGRAM |||| * ******************************************** The VALIDATED compilers tested were: DEC, DDC, ALS(1.6), Telesoft(2.1), Karlsruhe(1.3), Alsys And the pre-releases : Gould/SEL, Alsys/Apollo. The ONLY compiler, which could produce a running program after minor modifications only, was the DEC compiler (the COUNT attribute of task failed to increment, and math procedures were named differently). ALL (ALL|) the others failed for all sorts of reasons, such as: pure crash of the compilers, 'heap full' problems, missing essential features (one compiler did e.g. not support instantiation of generic packages, that contains task declarations). The problems were such that major redesigns in order to work-around the problems would be required. In NO case the problem could be identified as a design error in the original Ada code (which was running without problems on the DG). Conclusions ? --- I refrain from the obvious conclusions, and just qoute what the compiler designers have been telling us over the years: 'A better Ada compiler will come out soon next year' Uffe K. Mortensen, The European Space Agency, ESA/ESTEC. Page 15 ASR Newsletter, Issue 9, Dec 86 - Jan 87 --------------------------------------------------------------------------- IV. NEW SUBMISSIONS TO THE ASR NEW SUBMISSIONS TO THE ASR 1. AJPO Validation Procedures and Guidelines ____ __________ __________ ___ __________ The file VALIDATE.INF in PD:<ADA.POINTERS> has been updated. The old version was dated 2/86, and the new version of 1/87 (which was announced last week at SigAda and on the net) has replaced it. VALIDATE.INF contains the Ada Joint Program Office Validation Procedures and Guidelines (issued 1 Jan 87). From the executive summary: "This document is intended for all Ada Programming Language users and compiler Vendors who have an interest in Ada Validations. It defines commonly used Ada Validation terms; outlines the organizational structure to manage, coordinate, and direct the Ada Validation process; lists steps in the process; and provides guidance to Department of Defense (DoD) program managers on the acquisition, use, and maintenance of Ada compilers." 2. Validated Ada Compilers List _________ ___ _________ ____ The latest list of validated Ada compilers is now in PD:<ADA.POINTERS> as COMPILERS.INF. This list is dated 1 Nov 86 and contains 64 compilers. 3. Compools in Ada ________ __ ___ Machine/System Compiled/Run on : VAX 11/780, VMS 4.4, DEC Ada Abstract : CPA - Compools in Ada CPA.SRC -- This file contains the programs for the compool like structure in Ada. This structure is similar to a common block. Directory: PD:<ADA.COMPONENTS> CPA.CMM 162 CPA.PRO 2397 CPA.SRC 2318 =============== ========== 3 Files 4877 4. Date ____ Machine/System Compiled/Run on : DEC VAX 11/750, DEC Ada v1.3 Abstract : This generic package provides arithmetic and logical operations for dates. It strongly parallels the required CALENDAR package, but differs primarily in the range of dates handled. Like CALENDAR, routines such as SPLIT, MONTH, DAY, and YEAR are available. The differences between this package and CALENDAR are reflected in the range of dates, the inclusion of a DAY_NAME function, and the ability to specify a date with a year and an annual Julian day number *. A day is the smallest unit of time in this package. An important feature is the ability to subtract dates over the full range of years. Thus, you can for example, calculate the number of days between 10/15/1986 and 1/1/1988. Another important feature is the ability to add (or subtract) x number of days from a date and obtain a date x days in the future (or past). Page 16 ASR Newsletter, Issue 9, Dec 86 - Jan 87 Directory: PD:<ADA.MATH> DATE.CMM 179 DATE.PRO 3380 DATE.SRC 52159 =============== ========== 3 Files 55718 5. Math Functions ____ _________ Machine/System Compiled/Run on : VAX 11/780, VMS 4.4, DEC Ada Abstract : MATHFUN - Selected math functions for integer and floating point math. Functions for one- and two-dimensional arrays are included. MATHFUN.SRC -- This file contains math functions and array functions programs with test programs. The programs include: 1) MATHGENI -- generic package of integer math functions 2) MATHGENF -- generic package of floating point math functions 3) MATHFUNG -- generic package of three component types 4) ARRAYFG1 -- generic package of vector functions 5) ARRAYFG2 -- generic package of two dimensional matrix functions 6) ARRAYFG -- generic package of three array component types Directory: PD:<ADA.MATH> MATHFUN.CMM 171 MATHFUN.DAT 11013 MATHFUN.PRO 2887 MATHFUN.SRC 28563 =============== ========== 4 Files 42634 6. FORTRAN Namelist Capability _______ ________ __________ Machine/System Compiled/Run on : VAX 11/780, VMS 4.4, DEC Ada Abstract : NAMELIST - An input package which implements the FORTRAN NAMELIST capability. Directory: PD:<ADA.COMPONENTS> NAMELIST.CMM 436 NAMELIST.PRO 2496 NAMELIST.SRC 21435 =============== ========== 3 Files 24367 7. Sort Array Update ____ _____ ______ Machine/System Compiled/Run on : DG MV10000, ROLM ADE VAX 11/780, DEC ACS RATIONAL R1000 (others) Abstract : This generic package contains several array sorting routines. Page 17 ASR Newsletter, Issue 9, Dec 86 - Jan 87 Directory: PD:<ADA.COMPONENTS> SORTARRY.ADA 62081 SORTARRY.CMM 638 SORTARRY.PRO 3380 =============== ========== 3 Files 66099 8. Ada, Software Engineering, and Common Blocks ____ ________ ____________ ___ ______ ______ Ed Berard's recent statements regarding Ada, Software Engineering, and the new common block submission have been placed in PD:<ADA.EDUCATION> in COMPOOLS.DOC. Additional material resulting from a discussion of this topic is included. 9. Planned Ada Implementations _______ ___ _______________ The latest list of planned Ada implementations (ie, in development) is in PD:<ADA.POINTERS>ADAPLANS.INF. The date of this file is Nov 86. 10. Documentation Update from ADA20 _____________ ______ ____ _____ The following files have been updated in the ASR on SIMTEL20. They were all FTPed from ADA20. The format for this information is ADA20_directory_filename => SIMTEL20_directory_filename PS:<ADA-INFO>ACVC.HLP => <ADA.POINTERS>ACVCSUITE.INF PS:<ADA-INFO>DOCU-REF.HLP => <ADA.POINTERS>ADADOC.INF PS:<ADA-INFO>ADA-DDN.HLP => <ADA.POINTERS>ADA1INFO.INF PS:<ADA-INFO>IMPL-MAT.HLP => <ADA.POINTERS>ADAPLANS.INF PS:<ADA-INFO>ADA-RBBS.HLP => <ADA.POINTERS>ADARBBS.INF PS:<ADA-INFO>AJPO-STF.HLP => <ADA.POINTERS>AJPOSTAFF.INF PS:<ADA-INFO>ALS-STAT.HLP => <ADA.POINTERS>ALSSTAT.INF PS:<ADA-INFO>ARTEWG-INFORMATION-ACCESS.HLP => <ADA.POINTERS>ARTEWG.INF PS:<ADA-INFO>ADA-BIB.HLP => <ADA.POINTERS>BIBORDER.INF PS:<ADA-INFO>CAISUPDT.HLP => <ADA.POINTERS>CAISSTAT.INF PS:<ADA-INFO>VAL-COMP.HLP => <ADA.POINTERS>COMPILERS.INF.9 PS:<ADA-INFO>CONTACTS.HLP => <ADA.POINTERS>CONTACTS.INF PS:<ADA-INFO>DIANA.HLP => <ADA.POINTERS>DIANA.INF PS:<ADA-INFO>DODDIREC.HLP => <ADA.POINTERS>DODD5000.INF PS:<ADA-INFO>EV-INFORMATION-ACCESS.HLP => <ADA.POINTERS>EVINFO.INF PS:<ADA-INFO>IMPGUIDE.HLP => <ADA.POINTERS>IMPGUIDE.DOC PS:<ADA-INFO>ISO-STAT.HLP => <ADA.POINTERS>ISO.INF PS:<ADA-INFO>KAPSE.HLP => <ADA.POINTERS>KAPSE.INF PS:<ADA-INFO>KIT-INFORMATION-ACCESS.HLP => <ADA.POINTERS>KITINFO.INF PS:<ADA-INFO>DEF-MCCR.HLP => <ADA.POINTERS>MCCR.INF PS:<ADA-INFO>NATO-ADA.HLP => <ADA.POINTERS>NATOADA.INF PS:<ADA-INFO>1750A.HLP => <ADA.POINTERS>ST1750A.INF PS:<ADA-INFO>TRADEMRK.HLP => <ADA.POINTERS>TRADEMARK.INF PS:<ADA-INFO>VALFACIL.HLP => <ADA.POINTERS>VALFACIL.INF PS:<ADA-INFO>VAL-POL.HLP => <ADA.POINTERS>VALIDATE.INF PS:<ADA-INFO>VALIDATION-INFORMATION-ACCESS.HLP => <ADA.POINTERS>VALINFO.INF PS:<ADA-INFO>GLOSSARY.HLP => <ADA.EDUCATION>GLOSSARY.DOC PS:<ADA-INFO>TEXT-BIB.HLP => <ADA.EDUCATION>TEXTBOOKS.BIB PS:<ADA-INFO>ADABOOKS.HLP => <ADA.EDUCATION>TEXTBOOKS.DOC Page 18 ASR Newsletter, Issue 9, Dec 86 - Jan 87 ============================================================================== Ada is a registered trademark, U.S. Government - Ada Joint Program Office. The following are trademarks of Digital Equipment Corporation: DEC, DECSYSTEM-20, ULTRIX, VAX, VMS. UNIX is a trademark of AT&T Bell Laboratories. The following are trademarks of Data General Corporation: AOS, ROLM. Verdix is a trademark of Verdix Corporation. TeleGen2 and TeleSoft are trademarks of TeleSoft. The Ada Software Repository Newsletter is Copyright 1986, 1987 Echelon, Inc. All Rights Reserved. Permission to reprint, wholly or partially, is automatically granted if source credit is given to Echelon. Echelon, Inc. 885 N. San Antonio Road Los Altos, CA 94022 USA Telephone: 415/948-3820 Page 19